Analysis and timeline visualization of storage channels

ABSTRACT

The visualization of a storage access on a timeline that represents various disk access events, such as a storage read event, or a storage write event. The storage access timeline may be formulated using event data gathered regarding storage access events, such as storage read requests, or storage write requests. The timeline may be displayed in conjunction with non-storage events, such as thread events, process events, processor events, or such, in order to give a visual indication of what is causing the storage access events. There may even be a control for displaying an identification of the file being accessed for one or more of the storage access events. With a better understanding of correlation between storage access events and application operation, optimization of the application itself may be achieved to more efficiently interface with the storage medium.

BACKGROUND

Computing systems are providing ever more complex and sophisticatedfunctionality. Such functionality is often primarily driven byunderlying software, which itself is becoming ever more complex.Application developers have the task of developing such software, andtuning performance to ensure efficient execution. Such applicationdevelopers and others might also have an interest in evaluating softwareperformance.

Application developers have a wide variety of tools at their disposal inorder to author software. First, source code allows the applicationdeveloper to author software using instructions that are moreunderstandable and intuitive to a human than is binary or intermediatecode. The source code is ultimately compiled and/or interpreted intobinary to allow readability of the code by a computing processor. Inaddition, various authoring tools allow for various visualizations thatallow a developer to have a good understanding of how the application iscurrently functioning. For instance, some authoring tools allow aprogrammer to step through the execution of a program, one line ofsource code at a time, and evaluate the values associated to variousparameters and variables. Authors might also insert temporary lines ofcode within the design for use in debugging.

Storage channel input/output is a major contributor to applicationperformance. Such storage channels may be for reading from a storagemedium, or in the case of a read/write medium, writing to the storagemedium. The storage medium might be, for example, a CD-ROM drive, a DVDdrive, a disk drive, and so forth. For instance, often applicationspause while storage input/output is being performed. One of thecontributing factors that makes storage input/output analysis difficultis that storage input/output involves the file system, which is usuallya service of the operating system. This means that it is also difficultto trace a storage input/output request all the way through the system,making correlation to the application difficult. Another challenge isthat storage input/output can result from indirect actions by theapplication or the operating system. For example, disk input/output canresult when an application access a memory location that causes a pagefault, when instructions from a dynamically linked library need to beloaded into memory, or when virtual memory operations are beingperformed by the operating system, and so forth.

BRIEF SUMMARY

Embodiments described herein relate to the analysis and visualization ofa storage access timeline that represents various storage access events,such as storage read events, or storage write events. The disk accesstimeline may be formulated using event data gathered during executionregarding storage access events, such as a storage read request, or astorage write request. The timeline may be displayed in conjunction withnon-storage events, such as thread events, process events, processorevents, or such, in order to give a visual indication of what is causingthe storage access events. There may even be a control for displaying anidentification of the file being accessed for one or more of the storageaccess events. With a better understanding of correlation betweenstorage access events and application operation, optimization of theapplication itself may be achieved to more efficiently interface withthe storage medium.

This Summary is not intended to identify key features or essentialfeatures of the claimed subject matter, nor is it intended to be used asan aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features can be obtained, a more particular descriptionof various embodiments will be rendered by reference to the appendeddrawings. Understanding that these drawings depict only sampleembodiments and are not therefore to be considered to be limiting of thescope of the invention, the embodiments will be described and explainedwith additional specificity and detail through the use of theaccompanying drawings in which:

FIG. 1 illustrates an example computing system that may be used toemploy embodiments described herein;

FIG. 2 illustrates a flowchart of a method for a computing system todisplay a visualization of a storage access timeline;

FIG. 3 illustrates an example architecture that may implement the methodof FIG. 2;

FIG. 4 illustrates an example user interface that might be displayedupon execution of the method of FIG. 2;

FIG. 5 illustrates a user interface that is similar to the userinterface of FIG. 4 except that a framing control is manipulated to zoominto a particular portion of the timeline; and

FIG. 6 illustrates a user interface that might replace the report frameof FIG. 5 if the profile report tab of FIG. 5 is selected.

DETAILED DESCRIPTION

In accordance with embodiments described herein, storage accesstimeline(s) is/are constructed based on underlying event data recordedduring execution of an application program, when storage access eventsoccur. First, some introductory discussion regarding computing systemswill be described with respect to FIG. 1. Then, various embodiments ofthe rendering of storage access timelines will be described withreference to FIGS. 2 through 6.

First, introductory discussion regarding computing systems is describedwith respect to FIG. 1. FIG. 1 illustrates a computing system, which mayimplement a message processor in software. Computing systems are nowincreasingly taking a wide variety of forms. Computing systems may, forexample, be handheld devices, appliances, laptop computers, desktopcomputers, mainframes, distributed computing systems, or even devicesthat have not conventionally considered a computing system. In thisdescription and in the claims, the term “computing system” is definedbroadly as including any device or system (or combination thereof) thatincludes at least one processor, and a memory capable of having thereoncomputer-executable instructions that may be executed by the processor.The memory may take any form and may depend on the nature and form ofthe computing system. A computing system may be distributed over anetwork environment and may include multiple constituent computingsystems.

As illustrated in FIG. 1, in its most basic configuration, a computingsystem 100 typically includes at least one processing unit 102 andmemory 104. The memory 104 may be physical system memory, which may bevolatile, non-volatile, or some combination of the two. The term“memory” may also be used herein to refer to non-volatile mass storagesuch as physical storage media, which physical storage media may beaccessed, and the storage access events being analyzed and visualized asdescribed herein. If the computing system is distributed, theprocessing, memory and/or storage capability may be distributed as well.As used herein, the term “module” or “component” can refer to softwareobjects or routines that execute on the computing system. The differentcomponents, modules, engines, and services described herein may beimplemented as objects or processes that execute on the computing system(e.g., as separate threads).

In the description that follows, embodiments are described withreference to acts that are performed by one or more computing systems.If such acts are implemented in software, one or more processors of theassociated computing system that performs the act direct the operationof the computing system in response to having executedcomputer-executable instructions. An example of such an operationinvolves the manipulation of data. The computer-executable instructions(and the manipulated data) may be stored in the memory 104 of thecomputing system 100.

Computing system 100 may also contain communication channels 108 thatallow the computing system 100 to communicate with other messageprocessors over, for example, network 110. Communication channels 108are examples of communications media. Communications media typicallyembody computer-readable instructions, data structures, program modules,or other data in a modulated data signal such as a carrier wave or othertransport mechanism and include any information-delivery media. By wayof example, and not limitation, communications media include wiredmedia, such as wired networks and direct-wired connections, and wirelessmedia such as acoustic, radio, infrared, and other wireless media. Theterm computer-readable media as used herein includes both storage mediaand communications media.

Embodiments within the scope of the present invention also includecomputer-readable media for carrying or having computer-executableinstructions or data structures stored thereon. Such computer-readablemedia can be any available media that can be accessed by a generalpurpose or special purpose computer. By way of example, and notlimitation, such computer-readable media can comprise physical storageand/or memory media such as RAM, ROM, EEPROM, CD-ROM or other opticaldisk storage, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to carry or store desired programcode means in the form of computer-executable instructions or datastructures and which can be accessed by a general purpose or specialpurpose computer. When information is transferred or provided over anetwork or another communications connection (either hardwired,wireless, or a combination of hardwired or wireless) to a computer, thecomputer properly views the connection as a computer-readable medium.Thus, any such connection is properly termed a computer-readable medium.Combinations of the above should also be included within the scope ofcomputer-readable media.

Computer-executable instructions comprise, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions. Although the subject matter has been described inlanguage specific to structural features and/or methodological acts, itis to be understood that the subject matter defined in the appendedclaims is not necessarily limited to the specific features or actsdescribed herein. Rather, the specific features and acts describedherein are disclosed as example forms of implementing the claims.

Optionally, the computing system may include a display 112 fordisplaying visualizations. For instance, if the computing systemperforms the method 200 of FIG. 2, the visualization of the disk accesstimeline of the execution of the target program may be rendered at thecomputing system 100. Having described a computing system that may beused to implement features of the principles described herein withrespect to FIG. 1, embodiments of the formulation of a timeline of diskaccess events will be described with respect to FIGS. 2 through 6.

FIG. 2 illustrates a flowchart of a method 200 for a computing system toanalyze and display a visualization of a storage access timeline. Themethod 200 is performed upon execution of an application program (act201) that is being evaluated. The method 200 may be performed by thecomputing system 100 of FIG. 1, which may have one or more storagemediums that are accessed to support the execution of the applicationprogram. It is these storage accesses that are to be evaluated as partof the overall evaluation of the application program. The storage mediamay include, for example, disk drives, CD-ROM drives, DVD drivers, orany other medium that can persistently hold data that can be readtherefrom and/or can be written thereto.

During execution (act 201) of the application program, the storagemedium or media may be accessed multiple times. This is symbolicallyrepresented by the decision block 202 internal to the act 201. At leastsome, and preferably all, of the times that the execution (act 201)results in a storage access event (Yes in decision block 202). In such acase, event data may be collected corresponding to the storage access(act 203). The event data may be any data that is helpful toconstructing a storage access timeline, and populating the timeline withinformation that may be used to evaluate the program operation. As anexample, such event data may include 1) the type of storage accessrequest (e.g., read versus write), 2) the time that the storage accesswas initiated, 3) the storage medium identity that is being accessed(e.g., disk 0, disk 1, CD-ROM 0, CD-ROM 1, DVD-0, DVD-1, and so forth),4) the identifier for the file that is being accessed, 5) the identifierfor the thread that initiated the request, 6) the identifier for theprocess that initiated the request, 7) the state of the callstack at thetime of the storage access, and so forth. The system may assign anidentifier for the storage access request, which may also be recorded.Also, upon a storage access request completing, further event data maybe gathered such as 1) the identifier for the storage access that wasassigned by the system, 2) the time that the storage access wascompleted, and 3) the number of bytes involved in the request (i.e., thenumber of bytes read, or the number of bytes written). The latency ofthe storage access request may be computed from the event data for theinitiation and completion of a storage access request. The generation ofsuch events may be performed, for example, using the Event Tracing forWindows (ETW) tracing mechanism in the case of an application programthat runs using the MICROSOFT® WINDOWS® operating system. In any case,regardless of whether the application may be run in WINDOWS or not,there may be an underlying infrastructure that allows for configuring ofgenerated events.

If there were a single storage medium, then there may be storage readrequests in which data is read from the storage medium, and storagewrite requests in which data is written to the storage medium. If thereare multiple storage media available to the computing system executingthe application program, then there may be storage read and storagewrite requests for each of the available storage media. Of course, thismeans that there might be multiple concurrent storage access requests inwhich at least a portion of one storage access request overlaps all or aportion of each of one or more other storage access requests. Further,even within a single storage medium, there might be overlapping storageaccesses.

In one embodiment, the disk access timeline(s) are to be rendered alongwith one or more non-storage access timelines. The storage accesstimeline(s) and the non-storage access timeline(s) may be rendered usinga common time reference. For instance, the non-disk access timelinesmight be thread timelines in which information regarding various threadevents is illustrated. In the examples of FIGS. 4 and 5, the threadtimelines are illustrated with a common time reference with the storageaccess timelines (in this case disk access timelines), with timerepresented uniformly across all timelines with horizontal spacingdeterministically representing time across all timelines.

In order to construct such non-storage access timelines, event dataregarding non-storage events are also collected during execution of theapplication program. For instance, if thread timelines are to beconstructed, the event data might be 1) when an identified thread beginsactive execution, 2) when an identified thread ends active execution,and so forth. The timeline data might also include the state of thecallstack at periodic intervals. The gathered data may be organized intoa schema, which may even be a custom schema that is fully or partlydefined by the evaluator. Of course, these are just examples of eventsfrom which a timeline of execution may be constructed. The principlesdescribed herein are not limited to the particular types of executionevents. The non-storage events may also be generated using the ETWframework in the case of WINDOWS, or another type of underlying eventingframework in the case of application programs that do not run inWINDOWS.

Once the portion of the execution that is to be evaluated is completed,the storage access timeline(s) may be formulated (act 211) using atleast a portion of the collected event data. For instance, if there weretwo storage media, each being written to, and each being read from,there may be a total of four timelines illustrated as in the case ofFIG. 4. However, there might also be only two timelines illustrated, inwhich storage reads and storage writes are somehow distinguished fromeach other, perhaps by color. A storage read timeline may be constructedby using only the event data correspondence to storage reads for thestorage medium of interest, and finding the corresponding start and endtimes for each storage read. Likewise, a storage write timeline may beconstructed by using only the event data corresponding to storage writesfor the storage media of interest, and finding the corresponding startand end times for each storage write. Non-storage timelines may also beconstructed based on the time recorded for corresponding non-storageevents (e.g., when a thread begins active execution, and when a threadends active execution). The storage access timelines (and potentiallythe non-storage timelines) are then displayed (act 212).

FIG. 3 illustrates an example architecture 300 that may be instantiatedin the memory of the computing system upon execution of the method 200although some or all of the illustrated components may also beimplemented in hardware or a combination or software and hardware toformulate a computer program product.

The architecture 300 includes an event generation module 310 configuredto detect storage access events that occur during the execution of thetarget program, and generate timeline details of each of at least someof the detected storage access events. The events generation module 310may also generate non-storage events as mentioned above. The ETWframework is an example of the events generation module 310.

A collections module 320 collects the timeline details of each of atleast some of the detected storage access events or the other generatedevents. The collections module 320 may also evaluate and sort throughthe various events to formulate an in-memory representation of storageaccess timeline(s) and perhaps non-storage timeline(s).

The rendering module 330 renders the timelines formulated by thecollections module 320, or perhaps itself interprets the collectedtimeline details of the generated events to first formulate an in-memoryrepresentation of the timeline(s).

FIG. 4 illustrates an example user interface 400 that might be displayedupon execution of the method 200 of FIG. 2. Here, four disk accesstimelines 401 are displayed including a disk read timeline 401A and adisk write timeline 401B corresponding to one disk (identified as “Disk0”), and a disk read timeline 401C and a disk write timeline 401Dtimeline corresponding to another disk (identified as “Disk 1”). Here,approximately 11 seconds of execution are timelined.

A variety of non-disk timelines are also illustrated. In this case,eight thread timelines 402 are illustrated including a main threadtimeline 402A, and seven worker thread timelines 402B, 402C, 402D, 402E,402F, 402G and 402H. Here, various colors may represent different statusfor the corresponding thread or disk access channel. For instance, greenrectangles (represented as being dot-filled) may represent an executingthread, red rectangles (represented as being diagonal-filled in onedirection) may represent a non-executing thread, and pink rectangles(represented as being diagonal-filled leaning in the other direction)may represent a disk access event.

FIG. 5 illustrates a user interface 500 that is similar to the userinterface 400 of FIG. 4 except that now a framing control 513 ismanipulated to zoom into a particular portion of the timeline. Here,that portion is from about time 9.938 seconds to 10.042 seconds. At thisgranularity, one can distinguish three distinct disk reads 501A, 501Band 501C, and one distinct disk write 502. Also, one can distinguishthat the main thread transitions from a non-executing synchronizationstate 511A, to a very brief executing state 511B. Then at the precisemoment that the disk reads begin, the main thread transitions from anexecuting state 511B to the non-executing I/O state 511C (indicative ofa thread that is waiting for some I/O to complete). For this, theevaluator can infer that the main thread caused the disk I/O, and thatthe main thread is waiting for the disk I/O to complete beforecontinuing execution.

From this information, the evaluator may do a number of things, such asperhaps reconfiguring the program such that some other thread executessome non-dependent task while the main thread is waiting for the diskI/O to complete, thereby making the application program more efficient.Another thing that an evaluator can do is select the disk access rangeto identify the file being accessed. For instance, if selecting therectangle 501A, the user might be displayed a report identifying thefile being accessed.

FIG. 5 also illustrates a report frame 520 that illustrates informationregarding the timeline being viewed. Here, the current stack tab 522 isselected to thereby illustrate the current stack of the timeline beingillustrated. FIG. 6 illustrates a user interface 600 that might replacethe report frame 520 if the File Operations text 521 is selected. Here,a report is presented that is organized by thread and filename. Eachentry contains a summary of all access of the same file by the samethread, including the number of reads or writes, the number of bytesinvolved, and so forth. In the illustrated case of FIG. 6, there arefour line-items, each representing a file that is accessed by workerthread 1740. Each line-item entry represents, from left to right, thethread identifier of the thread that initiated the disk access, thefilename of the file being accessed by the disk access, the number ofreads involved in the disk access (0 if the disk access is a diskwrite), the number of bytes read (0 if the disk access is a disk write),the read latency (0 if the disk access is a disk write), the number ofwrites involved in the disk access (0 if the disk access is a diskread), the number of bytes written (0 if the disk access is a diskread), and the write latency (0 if the disk access is a disk read).

Accordingly, the principles described herein permit an evaluator tounderstand detailed information regarding disk access requests thatoccur during execution of an application program, and further understandthe various relationships between the disk accesses and other non-diskevents, such as thread execution.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed is:
 1. A method for a computing system to formulate anddisplay a visualization of a storage access timeline, the methodcomprising: an act of a computing system executing an applicationprogram, wherein the execution of the application program results in aplurality of accesses to a storage medium, the computing systemcomprising at least one processor; for at least some of the plurality ofaccesses, an act of the computing system collecting event datacorresponding to the storage accesses; an act of the computing systemformulating a storage access timeline of at least a subset of the atleast some of the plurality of accesses using at least a portion of theevent data corresponding to the at least the subset; and an act of thecomputing system displaying a representation of the storage accesstimeline.
 2. A method in accordance with claim 1, wherein the storageaccess timeline is displayed along with a non-storage timeline.
 3. Amethod in accordance with claim 2, wherein the storage access timelineand the non-storage timeline are displayed in a common time reference.4. A method in accordance with claim 2, wherein the non-storage timelineincludes a plurality of timelines corresponding to each of a pluralityof threads.
 5. A method in accordance with claim 1, further comprisingthe following for at least one of the storage accesses of the at leastthe subset: an act of displaying a file being accessed by thecorresponding storage access.
 6. A method in accordance with claim 1,further comprising the following for at least one of the storageaccesses of at least the subset: an act of displaying a representationof a latency of the corresponding storage access.
 7. A method inaccordance with claim 1, wherein at least one of the storage accesses isa disk access.
 8. A method in accordance with claim 1, furthercomprising the following for at least a one of the disk accesses of theat least the subset: an act of displaying a file being accessed by thecorresponding storage access; and an act of displaying a representationof a latency of the corresponding storage access.
 9. A method inaccordance with claim 1, wherein the storage access timeline includes astorage write timeline for a particular storage medium, and a storageread timeline for a particular storage medium.
 10. A method inaccordance with claim 1, wherein the storage access timeline includes atleast one timeline for a first storage medium, and at least one timelinefor a second storage medium.
 11. A method in accordance with claim 1,further comprising: an act of providing a framing control that permits auser to narrow in on a particular subset of the storage access timeline.12. One or more hardware storage device having stored thereon one ormore computer-executable instructions that, when executed by one or moreprocessor of a computing system during execution of a target program,cause the computing system to implement a method that includes thefollowing: the computer system instantiating an events generation moduleconfigured to detect storage access events that occur during theexecution of the target program, and generate timeline details of eachof at least some of the detected storage access events; the computingsystem instantiating a collections module that collects timeline detailsof each of at least some of the detected storage access events; and thecomputing system instantiating a rendering module configured tointerpret the collected timeline details and render a timeline of thestorage accesses that occur during execution of the target program. 13.The one or more hardware storage device in accordance with claim 12,wherein the rendering module displays the storage access timeline alongwith a non-storage timeline using a common time reference.
 14. The oneor more hardware storage device in accordance with claim 13, wherein thecollections module collects timeline details for non-storage accessevents, and the rendering module interprets the collected timelinedetails for the non-storage access events to thereby generate thenon-storage timeline.
 15. The one or more hardware storage device inaccordance with claim 14, wherein the non-storage timeline includes aplurality of timelines corresponding to each of a plurality of threads.16. The one or more hardware storage device in accordance with claim 12,wherein the rendering module is further configured to display at leastone of the following for a given storage access: a file identifier beingaccessed by the corresponding storage access; and a representation of alatency of the corresponding storage access.
 17. The one or morehardware storage device in accordance with claim 12, wherein therendering module is further configured to display all of the followingfor a given storage access: a file identifier being accessed by thecorresponding storage access; and a representation of a latency of thecorresponding storage access.
 18. The one or more hardware storagedevice in accordance with claim 12, wherein the rendering module isconfigured to simultaneously display at least one of the following foreach of a plurality of concurrent storage accesses: a file identifierbeing accessed by the corresponding storage access; and a representationof a latency of the corresponding storage access.
 19. The one or morehardware storage device in accordance with claim 12, wherein therendering module is configured to simultaneously display all of thefollowing for each of a plurality of concurrent storage accesses: a fileidentifier being accessed by the corresponding storage access; and arepresentation of a latency of the corresponding storage access.
 20. Acomputing system comprising: at least one processor; and one or morestorage device having stored computer-executable instructions which,when executed by the at least one processor, implement a method forformulating and displaying a visualization of a storage access timeline,wherein the method includes: an act of the computing system executing anapplication program, wherein the execution of the application programresults in a plurality of accesses to a storage medium; for at leastsome of the plurality of accesses, an act of the computing systemcollecting event data corresponding to the storage accesses; an act ofthe computing system formulating a storage access timeline of at least asubset of the at least some of the plurality of accesses using at leasta portion of the event data corresponding to the at least the subset;and an act of the computing system causing a display of a representationof the storage access timeline.